Minor thought, the right thing to do might be to discard any telemetry data collected from the period this command was broken.

The telemetry disable command was broken in e69def2 (by me, sigh) - but this is the first report we have had about this problem, which is interesting.

Affected versions are >=6.1.0, which was published on 30th of April 2024.

$ keystone telemetry disable
telemetry disable is an unknown command

As we want to err on the side of consent being missed, I think we could do the following:

• Delete project events where @keystone-6/core === 6.1.0 and @keystone-6/core === 6.2.0
• Delete ALL device events between 2024-04-29 (N-1) and 2024-??-??

The nature of device events being unversioned however results in an ongoing problem that we would not know if device events are coming from a device with @keystone-6/core === 6.1.0 or @keystone-6/core === 6.2.0. In light of that, I think the easiest conclusion is to shutdown the current telemetry.keystonejs.com/v1/ endpoint and activate a new, different endpoint in a future pull request; deleting any data >= 2024-04-29.

• Shutdown telemetry.keystonejs.com/v1/
• Retrieve final snapshot of the database, and destroy upstream copy
• Delete project events where "reportedAt" >= '2024-04-29'
• Delete device events where "reportedAt" >= '2024-04-29'
• Delete any events older than 1 year from the snapshot in accordance with our telemetry privacy policy

I'm open to feedback on this from the community, and thanks @DavidMulder0 for reporting this.
The response may seem reactive, but I think it's important to show that we respect any data collected from the community.

DELETE FROM "DeviceEvent" WHERE "reportedAt" <= NOW() - INTERVAL '1 year';
DELETE FROM "DeviceEvent" WHERE "reportedAt" >= '2024-04-29';
DELETE FROM "ProjectEvent" WHERE "reportedAt" <= NOW() - INTERVAL '1 year';
DELETE FROM "ProjectEvent" WHERE "reportedAt" >= '2024-04-29';

Merged as 830d46d